<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core">

<ui:composition template="/WEB-INF/template/geral.xhtml">
	<ui:define name="corpo">
		
		<div class="principal">
			GERENCIAMENTO DE MUDANÇAS
Mudanças ocorrem corriqueiramente em projetos de software com certo nível de complexidade, devido a vários fatores, como por exemplo, a inserção de novos requisitos ou modificação destes, para garantir que as mudanças ocorreram, porém de maneira controlada tem-se que utilizar alguns procedimentos de gerenciamento junto de ferramentas para apoio.
Procedimentos de gerencia são responsáveis por avaliar o custo benefício das mudanças propostas. O primeiro passo para o gerenciamento de configuração é fazer um formulário de mudança (Change Request Form) dizendo quais são as mudanças necessárias, nisso ele armazena todas as informações da mudança, como data da implementação no sistema, quando foi solicitada e outros.
Depois de enviar o formulário, ele vai ser registrado no banco de dados, e então é analisado para saber se aquela mudança é realmente necessária. Algumas mudanças podem ser rejeitadas, mais nem sempre é defeito do sistema, podendo ser que a mudança não seja necessária ou a mudança já foi considerada.
Processo de alteração
Depois que a mudança é aceita é avaliado o impacto dela no custo, no resto do sistema, nos componentes afetados, tudo isso usando as informações do banco de dados e do código-fonte do software, depois disso é que se saberá quanto vai custar a mudança no orçamento do projeto.
O comitê de controle de mudanças (CCB) deve revisar e aprovas as mudanças, desde que não sejam mudanças consideras mínimas, e é ele que decide se a mudança é justificada do ponto de vista financeiro e também decide quais mudanças priorizar.
Fatores importantes para decidir se a aprovação ou desaprovação da mudança são:
1 - As consequências de não fazer a mudança: Ao optar por uma avaliação na mudança, você deve pensar no que aconteceria se a mudança não ocorresse, no caso de uma falha grave no sistema, como uma interrupção na operação do sistema, ou uma falha de prioridade baixa como uma core incorretas em um display.
2 - Os Benefícios da mudança: A mudança é algo que beneficiará muitos usuários do sistema ou somente (principalmente) o solicitante?
3 - O número de usuários afetados pela mudança: Se apenas alguns usuários forem afetados, a mudança pode receber prioridade baixa ou desaconselhada.
4 - Os custos de se fazer a mudança: Se fazer a mudança afetar muitos outros componentes de sistemas, aumentando a chance de surgirem novos bugs, ela pode ser rejeitada.
5 - O Ciclo de release: Se acaba de ser liberada uma nova versão do software para os clientes, pode fazer sentido atrasar a implementação da mudança até o próximo release planejado.
		</div>	
		
	</ui:define>
</ui:composition>
</html>